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For Organisations 


Data Protection Impact Assessments can be used to identify and mitigate against any data 
protection related risks arising from a new project, which may affect your organisation or the 
individuals it engages with. Read this guide to learn more about how and when to carry out a 
DPIA. 


e Under the GDPR, DPIAs will be mandatory for any new high risk processing projects. 

e The DPIA process will allow you to make informed decisions about the acceptability of 
data protection risks, and communicate effectively with the individuals affected. 

e Notall risks can be eliminated, but a DPIA can allow you to identify and mitigate against 
data protection risks, plan for the implementation of any solutions to those risks, and 
assess the viability of a project at an early stage. 

e Ifa DPIA does not identify mitigating safeguards against residual high risks, the Data 
Protection Commissioner must be consulted. 

e Good record keeping during the DPIA process can allow you to demonstrate compliance 
with the GDPR and minimise risk of a new project creating legal difficulties. 


What is a Data Protection Impact Assessment? 


When your organisation collects, stores, or uses personal data, the individuals whose data you 
are processing are exposed to risks. These risks range from personal data being stolen or 
inadvertently released and used by criminals to impersonate the individual, to worry being 
caused to individuals that their data will be used by your organisation for unknown purposes. A 
Data Protection Impact Assessment (DPIA) describes a process designed to identify risks arising 
out of the processing of personal data and to minimise these risks as far and as early as 
possible. DPIAs are important tools for negating risk, and for demonstrating compliance with the 
GDPR. 


This document assumes that a DPIA will be conducted for a defined project, rather than for an 
organisation's operations as a whole. A particular function of your organisation, or a programme 
of changes to your organisation's operations as a whole, may be viewed as a project. 


What are the benefits of conducting a DPIA? 


Conducting a DPIA will improve awareness in your organisation of the data protection risks 
associated with a project. This will help to improve the design of your project and enhance your 
communication about data privacy risks with relevant stakeholders. Some of the benefits of 
conducting a DPIA are as follows: 


e Ensuring and demonstrating that your organisation complies with the GDPR and avoids 
sanctions. 

e Inspiring confidence in the public by improving communications about data protection 
issues. 

e Ensuring your users are not at risk of their data protection rights being violated. 

e Enabling your organisation to incorporate “data protection by design” into new projects. 





e Reducing operation costs by optimising information flows within a project and 
eliminating unnecessary data collection and processing. 

e Reducing data protection related risks to your organisation. 

e Reducing the cost and disruption of data protection safeguards by integrating them into 
project design at an early stage. 


Data protection by design means embedding data privacy features and data privacy enhancing 
technologies directly into the design of projects at an early stage. This will help to ensure better 
and more cost-effective protection for individual data privacy. 


Data protection by default means that service settings must be automatically data protection 
friendly. 


While long recommended as good practice, both of these principles are enshrined in law under 
the GDPR (Article 25). 


How do I know if a DPIA should be conducted? 


Read: List of Types of Data Processing Operations which require a Data Protection Impact 
Assessment 





Under the GDPR, a DPIA is mandatory where data processing “is likely to result in a high risk to 
the rights and freedoms of natural persons”. This is particularly relevant when a new data 
processing technology is being introduced. In cases where it is not clear whether a DPIA is strictly 
mandatory, carrying out a DPIA is still good practice and a useful tool to help data controllers 
comply with data protection law. 


The GDPR provides some non-exhaustive examples of when data processing is “likely to result in 
high risks”: 


e “A systematic and extensive evaluation of personal aspects relating to natural persons 
which is based on automated processing, including profiling, and on which decisions are 
based that produce legal effects concerning the natural person or similarly significantly 
affect the natural person.” 

e “Processing on a large scale of special categories of data referred to in Article 9(1), or of 
personal data relating to criminal convictions and offences referred to in Article 10.” 

e “A systematic monitoring of a publicly accessible area on a large scale.” 


The Article 29 Working Party, consisting of the representatives from each data protection 
authority in the EU, has adopted guidelines on DPIAs and whether processing is likely to result in 
a high risk for the purposes of the GDPR. The guidelines are available here. In assessing whether 
processing is likely to result in a high risk the Article 29 Working Party has set forth the following 
criteria to consider: 


1. Evaluation or scoring, including profiling and predicting, especially “from aspects 
concerning the data subject's performance at work, economic situation, health, personal 
preferences or interests, reliability or behaviour, location or movements” (recitals 71 and 
91). Examples of this could include a bank that screens its customers against a credit 
reference database, or a biotechnology company offering genetic tests directly to 





consumers in order to assess and predict the disease/health risks, or a company building 
behavioural or marketing profiles based on usage or navigation on its website. 
Automated decision making with legal or similar significant effect: processing that aims 
at taking decisions on data subjects producing “legal effects concerning the natural 
person” or which “similarly significantly affects the natural person” (Article 35 (3)(a)). For 
example, the processing may lead to the exclusion or discrimination against individuals. 
Processing with little or no effect on individuals does not match this specific criterion. 
Systematic monitoring: processing used to observe, monitor or control data subjects, 
including data collected through “a systematic monitoring of a publicly accessible area” 
(Article 35 (3)(c)). This type of monitoring is a criterion because the personal data may be 
collected in circumstances where data subjects may not be aware of who is collecting 
their data and how they will be used. Additionally, it may be impossible for individuals to 
avoid being subject to such processing in frequent public (or publicly accessible) space(s). 
Sensitive data: this includes special categories of data as defined in Article 9 (for example 
information about individuals’ political opinions), as well as personal data relating to 
criminal convictions or offenses. An example would be a general hospital keeping 
patients’ medical records or a private investigator keeping offenders’ details. This 
criterion also includes data which may more generally be considered as increasing the 
possible risk to the rights and freedoms of individuals, such as electronic communication 
data, location data, financial data (that might be used for payment fraud). In this regard, 
whether the data has already been made publicly available may be considered as a 
factor in the assessment if the data was expected to be further used for certain 
purposes. This criterion may also include information processed by a natural person in 
the course of purely personal or household activity (such as cloud computing services for 
personal document management, email services, diaries, e-readers equipped with note 
taking features, and various life-logging applications that may contain very personal 
information), whose disclosure or processing for any other purpose than household 
activities can be considered as very intrusive. 
Data processed on a large scale: the GDPR does not define what constitutes large-scale, 
though recital 91 provides some guidance. In any event, the WP29 recommends that the 
following factors, in particular, be considered when determining whether the processing 
is carried out on a large scale: 

1. The number of data subjects concerned, either as a specific number or as a 

proportion of the relevant population. 

2. The volume of data and/or the range of different data items being processed. 

3. The duration, or permanence, of the data processing activity. 

4. The geographical extent of the processing activity. 
Datasets that have been matched or combined, for example originating from two or 
more data processing operations performed for different purposes and/or by different 
data controllers in a way that would exceed the reasonable expectations of the data 
subject. 
Data concerning vulnerable data subjects (recital 75): the processing of this type of data 
can require a DPIA because of the increased power imbalance between the data subject 
and the data controller, meaning the individual may be unable to consent to, or oppose, 
the processing of his or her data. For example, employees would often meet serious 
difficulties to oppose to the processing performed by their employer, when it is linked to 
human resources management. Similarly, children can’t be considered as not able to 
knowingly and thoughtfully oppose or consent to the processing of their data. This also 
concerns more vulnerable segments of the population requiring special protection, such 
as, for example, the mentally ill, asylum seekers, or the elderly, a patient, or in any case, 





where an imbalance in the relationship between the position of the data subject and the 
controller can be identified. 

8. Innovative use or applying technological or organisational solutions, like combining use 
of finger print and face recognition for improved physical access control, etc. The GDPR 
makes it clear (Article 35(1) and recitals 89 and 91) that use of a new technology can 
trigger the need to carry out a DPIA. This is because the use of a new technology can 
involve novel forms of data collection and usage, possibly with a high risk to individuals’ 
rights and freedoms. Indeed, the personal and social consequences of the deployment of 
a new technology may be unknown. A DPIA will help the data controller to understand 
and to treat such risks. For example, certain “Internet of Things” applications could have 
a significant impact on individuals’ daily lives and privacy; and therefore require a DPIA. 

9. Data transfer across borders outside the European Union (recital 116), taking into 
consideration, amongst others, the envisaged country or countries of destination, the 
possibility of further transfers, or the likelihood of transfers based on derogations for 
specific situations set forth by the GDPR. 

10. When the processing in itself “prevents data subjects from exercising a right or using a 
service or a contract” (Article 22 and recital 91). This includes processing performed in a 
public area that people passing by cannot avoid, or processing that aims at allowing, 
modifying or reusing data subjects’ access to a service or entry into a contract. An 
example of this is where a bank screens its customers against a credit reference 
database in order to decide whether to offer them a loan. 


The Working Party considers that the more criteria are met by the processing, the more likely it is 
to present a high risk to the rights and freedoms of data subjects, and therefore to require a 
DPIA. As a rule of thumb, a processing operation meeting less than two criteria may not require 
a DPIA due to the lower level of risk, and processing operations which meet at least two of these 
criteria will require a DPIA. If the controller believes that a processing operation which meets at 
least two of these criteria is not likely to be high risk, the controller should thoroughly document 
the reasons for not carrying out a DPIA. 


When is a DPIA not required? 


A DPIA is generally not required in the following cases: 


e Where the processing is not “likely to result in a high risk to the rights and freedoms of 
natural persons” (article 35(1)). 

e When the nature, scope, context and purposes of the processing are very similar to the 
processing for which DPIAs have been carried out. In such cases, results of a DPIA for 
similar processing can be used (Article 35(1)). 

e Where a processing operation has a legal basis in EU or Member State law and has 
stated that an initial DPIA does not have to be carried out, where the law regulates the 
specific processing operation and where a DPIA, according to the standards of the GDPR, 
has already been carried out as part of the establishment of that legal basis (Article 
35(10)). 

e Where the processing is included on the optional list (established by the supervisory 
authority) of processing operations for which no DPIA is required (Article 35(5)). Such a 
list may contain processing activities that comply with the conditions specified by this 
authority, in particular through guidelines, specific decisions or authorisations, 
compliance rules, etc. In such cases, and subject to reassessment by the competent 
supervisory authority, a DPIA is not required, but only if the processing falls strictly within 





the scope of the relevant procedure mentioned in the list and continues to comply fully 
with the relevant requirements. 


Is a DPIA mandatory for existing processing operations, existing before the GDPR 


becomes effective on the 25 May 2018? 





The GDPR is effective from the 25 May 2018, and DPIAs are legally mandatory only for 
processing operations that are initiated after this date. Nevertheless, the Article 29 Working 
Party strongly recommends carrying out DPIAs for all high risk operations prior to this date. 
Indeed a DPIA can be a powerful tool in ensuring that any operations commencing now will not 
leave you at risk of non-compliance once the law changes on the 25 May 2018, and save your 
organisation from operational disruption by allowing you to future proof new projects against 
the GDPR at an early stage. 


Additionally, new DPIAs or reviews of DPIAs for existing processing that commenced before the 
25 May 2018 may be required after that date in the following circumstances: 


e Where a significant change to the processing operation has taken place after the GDPR 
takes effect. For example, when a new technology comes into use, or when data is being 
used for a different purpose. In these cases the processing is effectively a new operation 
and could require a DPIA. 

e When there is a change of the risk presented by the processing operation. The risks and 
level of risk can change as a result of a change to one of the components of the 
processing operation (data, supporting assets, risk sources, etc.), or because the context 
of the processing evolves (purpose, functionalities, etc.). Data processing systems can 
evolve over time, and new threats and vulnerabilities can arise. 

e The organisational or societal context for the processing activity has changed, for 
example because the effects of certain automated decisions have become more 
significant, new categories of natural persons become vulnerable to discrimination or the 
data is intended to be transferred to data recipients located in a country which has left 
the EU. 


As a matter of good practice, the Article 29 Working Party recommends that all DPIAs should be 
re-assessed after 3 years, or sooner if circumstances have changed quickly. 


When in a project lifecycle should a DPIA be conducted? 


The DPIA should be carried out “prior to the processing” (GDPR Articles 35(1) and 35(10), recitals 
90 and 93). It is generally good practice to carry out a DPIA as early as practical in the design of 
the processing operation. It may not be possible to conduct a DPIA at the very inception of the 
project, as project goals and some understanding of how the project will operate must be 
identified before it will be possible to assess the data protection risks involved. 


For some projects the DPIA may need to be a continuous process, and be updated as the project 
moves forward. The fact that a DPIA may need to be updated once processing has actually 
started is not a valid reason for postponing or not carrying out a DPIA. 





Who should be involved in conducting the DPIA? 


The data controller is responsible for ensuring the DPIA is carried out. It may be delegated to 
someone else, inside or outside the organisation, but the data controller is ultimately 
accountable. 


The DPIA should be driven by people with appropriate expertise and knowledge of the project in 
question, normally the project team. If your organisation does not possess sufficient expertise 
and experience internally, or if a particular project is likely to hold a very high level of risk or 
affect a very large number of people, you may consider bringing in external specialists to consult 
on or to carry out the DPIA. 


A wide internal consultation process can benefit the DPIA, as some data protection risks will only 
be apparent to individuals working on specific aspects of the project. It will also allow you to gain 
feedback from those whose work will be affected by the project after implementation, such as 
engineers, designers and developers, who will have a practical knowledge of the operations. 
Involving your organisations public relations team will allow for effective communication of the 
DPIA’s outcomes to external stakeholders. 


Under the GDPR (Article 35), it is necessary for any data controller with a designated Data 
Protection Officer (DPO) to seek the advice of the DPO. This advice and the decisions taken 
should be documented as a part of the DPIA process. If a data processor is involved in the 
processing, the data processor should assist with the DPIA and provide any necessary 
information. 


e The Data Protection Officer (DPO) is a designated person appointed by an organisation 
to advise on data protection practices within the organisation. The DPO can be a staff 
member or an external service provider. Under the GDPR, appointment of a DPO is 
mandatory in the following circumstances: 

o For public bodies carrying out data processing, except for courts acting in their 
judicial capacity; 

o If the core activities of the organisation consist of data processing which, by 
virtue of their scope and/or purposes, require regular and systematic monitoring 
of data subjects on a large scale; or 

o The core activities of the organisation consist of processing on a large scale of 
special categories of data as outlined in Article 9 or personal data relating to 
criminal convictions as outlined in Article 10 of the GDPR. 


The data controller is bound to “seek the views of data subjects or their representatives” (Article 
35(9)), “where appropriate” in carrying out the DPIA. In some cases, the data subjects may be 
people within the organisation. Seeking the views of data subjects will allow the data controller 
to understand the concerns of those who may be affected, and to improve transparency by 
making individuals aware of how their information will be used. 


The views of data subjects can be sought through a variety of means, depending on the context. 
Staff could be consulted through a trade union; customers could be consulted by means of a 
survey. If the data controller's final decision differs from the views of data subjects, the reasons 
should be recorded as a part of the DPIA. If the data controller does not feel it appropriate to 
seek the views of data subjects, the justification for this should be documented. 





What steps are involved in carrying out a DPIA? 


The GDPR sets out the minimum features of a DPIA (Article 35(7), and recitals 84 and 90): 


e “a description of the envisaged processing operations and the purposes of the 
processing” 
e “an assessment of the necessity and proportionality of the processing” 
e “as assessment of the risks to the rights and freedoms of data subjects” 
e “the measures envisaged to: 
o “address the risks”; 
o “demonstrate compliance with this Regulation”. 


The GDPR presents a broad, generic framework for designing and carrying out a DPIA. This 
allows for scalability, so even the smallest data controllers can design and implement a DPIA; as 
well as for flexibility, so the data controller can determine the precise structure and form of the 
DPIA, allowing it to fit with existing working practices. 


Key elements of a successful DPIA 


The GDPR does not prescribe the exact process for carrying out a DPIA beyond the minimum 
features outlined above, allowing for flexibility and scalability in line with your organisation's 
needs. Although there is no one prescribed approach to take, the following steps can guide you 
through the process: 


1. Identifying whether a DPIA is required. 

2. Defining the characteristics of the project to enable an assessment of the risks to take 
place. 

Identifying data protection and related risks. 

Identifying data protection solutions to reduce or eliminate the risks. 

Signing off on the outcomes of the DPIA. 

Integrating data protection solutions into the project. 
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1. Identifying whether a DPIA is required 


You can use the steps described in the above section “How do | know if a DPIA is required” to 
assess if you need to perform a DPIA. This should take place as early as practicable in the 
lifecycle of the project. You will also need to identify the resources needed, the individuals who 
will be involved, and the timeframe of the DPIA process. 


As the nature and operational implications for data privacy of a project may not be apparent at 
an early stage in the planning, the DPIA may need to be an ongoing process, and may need to be 


reviewed or repeated as the project moves forward. 


2. Describing the information flows 


At an early point in the DPIA project, you should identify how it is intended to collect, store, use 
and delete personal information as part of the project. This exercise should also identify what 
kinds of information will be used as part of the project and who will have access to the 
information. 





The aim of this step is to get an early understanding of how information will be used as part of a 
project at each step along the process. This is crucial to being able to recognise the data privacy 
risks which may be posed by a project and to identifying what means might be used to mitigate 

those risks. 


You should consider if any new personal information will be generated by the project, and 
include it in your record of this stage. For example, a project involving the processing of 
psychometric tests might take one type of personal information (the answers to psychometric 
test questions) and process it to another (a psychometric profile). This new type of personal 
information is different in character, and so recording it separately in your map of information 
flows will help to ensure that its special characteristics are taken account of later in the DPIA 
process. 


This part of the DPIA will often mirror other elements of your project design process, such as a 
general scoping exercise to identify how the project will be carried out, and can be integrated 
with such a scoping exercise. Paying attention in the design of a project to how information will 
be used as part of the project may also yield efficiency benefits for your organisation by assisting 
you in streamlining processes for handling information. 


At this stage of the DPIA process, you should consult with internal stakeholders with a view to 
identifying the technical aspects of information collection, storage and processing, and how the 
different elements of the project will fit together in operation. You may also want to consult with 
external partners, who may be engaged by your organisation as a data processor, or to whom 
information might be disclosed as part of a project. 


This exercise should be documented using whatever means are most suitable for your 
organisation and the project concerned. Using visual aids, such as flow charts, to document how 
information will be used as part of a project can assist in identifying potential data privacy risks. 
This may also help with internal communication by better allowing the project team and others 
in your organisation to understand the design of the project. 


3. Identifying data protection and related risks 


This stage involves examining the project design to assess what data protection issues arise in 
the project, and to identify any risks it may expose individuals to, as well as any data protection- 
related risks that the project might create for your organisation. 


There are a range of different ways that an individual’s data privacy can be compromised or put 
at risk by a new project. The types of risk range from the risk of causing distress, upset or 
inconvenience to risks of financial loss or physical harm. There are equally as many kinds of data 
privacy-related risks to organisations, related to compliance issues and commercial factors. 
Breaches of the GDPR, such as excessive data processing or data breaches, can lead to 
significant penalties, as well as causing reputational damage to your organisation. 


This step should build upon work done at previous stages of the DPIA. The responses to the 
criteria laid out in the above section “How do | know if a DPIA should be conducted” should act as 
a guide to the risks which may be present. The map of information flows generated in stage 2 





may help you to identify particular weak spots, where general data privacy risks are likely to be 
particularly acute, or which might give rise to specific risks. 


For public sector bodies contemplating data processing measures that limit the EU fundamental 
right to data protection under Article 8 of the EU Charter of Fundamental Rights, a detailed 
analysis of the ‘necessity’ of the measure must be undertaken. Guidance published by the 
European Data Protection Supervisor will assist public sector policy makers in conducting the 
necessary analysis. The EDPS guidance is available 

at https://edps.europa.eu/sites/edp/files/publication/17-06-01_necessity toolkit_final_en_0.pdf 





Examples of the types of risks that you should be alert for at this stage of the DPIA process are 
outlined below. You should also examine sector-specific guidance which may be provided by 
regulators or industry groups in your area of operations, which can highlight types of risk which 
may be relevant for your organisation or project. 


You should take note of the magnitude of the risks identified, having regard to both the 
likelihood of a risk manifesting itself, and its impact. In assessing the severity of the risk, it is 
important to bear in mind the sensitivity of the personal data to be processed as part of the 
project, the number of people likely to be affected by any of the risks identified, and how they 
might be affected. 


You should keep a record of all risks identified at this stage. This will assist later on in the DPIA 
process in creating solutions to avoid or reduce those risks. Record keeping may be especially 
important in the event of an investigation or audit by the DPC. Good record keeping may help to 
demonstrate how your organisation complied with its obligations under the GDPR. 


This identification exercise should be carried out relatively early in the project design, as the 
sooner that data privacy risks can be identified, the easier and cheaper it will be to mitigate 
them. However, it is not a once-and-for-all exercise; you should keep the project design under 
review throughout the DPIA process to monitor the emergence of any new risks, which may 
occur by reason of a change to the design or scope of the project, and to assist in assessing 
which risk reduction techniques work. 


Your organisation can choose the risk management approach that best suits your existing 
project management process. The same tools you use for identifying other regulatory or 
commercial risks as part of your project management process can be used to assess the data 
protection risks involved in a project. The key point is to ensure that a methodological approach 
to identifying risks is adopted, and that records are kept of this process, and of all the risks 
identified. Your organisation may wish to maintain a data protection risk register to describe the 
risks associated with a project and assess their likelihood and impact. You can then go back to 
the register in the event of any changes to the project, to make note of any steps taken to 
mitigate risk, or any additional risks that emerge. This can be incorporated into an existing risk 
register if one exists for the project. Small scale projects may adopt a relatively informal 
approach to risk. You can still use a data protection risk register in such cases, but with the 
entries reflecting the less formal approach adopted. 


A data protection risk register is a master document that is used to record information about 
data protection risks which have been identified in relation to a particular project, as well as an 
analysis of risk severity and evaluations of the possible solutions to be applied. 





The data protection risk register should be updated as the project progresses, to reflect any 
solutions or new risks which have been identified. 


Example Risks To Individuals 


e Inappropriate disclosure of personal data internally within your organisation due to a 
lack of appropriate controls being in place. 

e Accidental loss of electronic equipment by organisation’s personnel may lead to risk of 
disclosure of personal information to third parties. 

e Breach of data held electronically by “hackers”. 

e Vulnerable individuals or individuals about whom sensitive data is kept might be affected 
to a very high degree by inappropriate disclosure of personal data. 

e Information released in anonymised form might lead to disclosure of personal data if 
anonymisation techniques chosen turn out not to be effective. 

e Personal data being used in a manner not anticipated by data subjects due to an 
evolution in the nature of the project. 

e Personal data being used for purposes not expected by data subjects due to failure to 
explain effectively how their data would be used. 

e Personal data being used for automated decision making may be seen as excessively 
intrusive. 

e Merging of datasets may result in a data controller having far more information about 
individuals than anticipated by the individuals. 

e Merging of datasets may inadvertently allow individuals to be identified from 
anonymised data. 

e Use of technology capable of making visual or audio recordings may be unacceptably 
intrusive, 

e Collection of data containing identifiers may prevent users from using a service 
anonymously. 

e Data may be kept longer than required in the absence of appropriate policies. 

e Data unnecessary for the project may be collected if appropriate policies not in place, 
leading to unnecessary risks. 

e Data may be transferred to countries with inadequate data protection regimes. 


Corporate Risks 


e Failure to comply with the GDPR may result in investigation, administrative fines, 
prosecution, or other sanctions. Failure to adequately conduct a DPIA where appropriate 
can itself be a breach of the GDPR. 

e Data breaches or failure to live up to customer expectations regarding privacy and 
personal data are likely to cause reputational risk. 

e Public distrust of your organisation’s use of personal information may lead to a 
reluctance on the part of individuals to deal with your organisation. 

e Problems with project design identified late in the design process, or after completion, 
may be expensive and cumbersome to fix. 

e Failure to manage how your company keeps and uses information can lead to inefficient 
duplication, or the expensive collection and storage of unnecessary information. 
Unnecessary processing and retention of information can also leave you at risk of non- 
compliance with the GDPR. 





e Any harm caused to individuals by reason of mishandling of personal data may lead to 
claims for compensation against your organisation. Under the GDPR you may also be 
liable for non-material damage. 


Compliance Risks 


Your organisation may face risks of prosecution, significant financial penalties, or reputational 
damage if you fail to comply with the GDPR. Individuals affected by a breach of the GDPR can 
seek compensation for both material and non-material damage. 


Failure to carry out a DPIA where appropriate is itself a breach of the legislation, as well as a lost 
opportunity to identify and mitigate against the future compliance risks a new project may bring. 


4. Identifying and evaluating data protection solutions 


This stage follows on from the identification of data protection risks at stage 3, with the aim of 
minimising the data privacy risk associated with the project, insofar as possible. In almost all 
cases, it will not be possible to eliminate data protection risks completely, but the aim of this 
stage is to balance those risks against the aims of the project, to ensure that any risks that are 
accepted are proportionate to the outcomes of the project. However, under GDPR, if there are 
remaining high risks, then you will need to consult with the Data Protection Commissioner, as 
described below. 


Data Protection solutions are steps which may be taken to reduce the likelihood or severity of 
data privacy risks being realised. 


During this stage, you should try to identify “data protection solutions” to reduce the impact of 
the project on data protection. You should do this by looking at each of the risks identified as 
part of the previous stage in the DPIA process and seeking to address it individually, or as part of 
a privacy solution which may address a number of risks together. 


In some cases, data protection solutions may be able to eliminate some types of risk, for 
example by abandoning unnecessary parts of a project which create unique risks. In others, data 
protection solutions may simply mitigate against risk or reduce the significance of data breaches, 
for example by adopting pseudonymisation to reduce the risk of identification of data subjects. 
The nature of these solutions will depend on the types of risk that have been identified, and the 
aims of the project. You should keep a full record of the process, to document any data 
protection solutions which have been identified, and which risks they were intended to address, 
as well as any risks which have been accepted. This can be done in a data protection risks 
register created under step 3. 


This step involves conducting a balancing exercise between the benefits to individuals and your 
organisation from the project, and the data protection and related risks to those individuals and 
your organisation. Equally, in assessing whether a particular data protection solution should be 
pursued, it is necessary to weigh up the costs and benefits of each solution. For example, 
anonymising data may help to prevent the risk of data relating to an identifiable person being 
accidentally disclosed to a third party, but it is likely to cost the organisation money to put an 
anonymisation system in place, and it may prevent some of the goals of the project from being 
realised (if those goals depend on processing information about identified individuals). 





Every project will have its own unique circumstances and risk profile, so there is no “one size fits 
all” set of data privacy solutions which may be adopted. However, the following are examples of 
data protection solutions, some of which may be applied in a range of different scenarios: 


e Deciding not to collect or store particular types of information. 

e Putting in place strict retention periods, designed to minimise the length of time that 
personal data is retained. 

e Reviewing physical and/or IT security in your organisation or for a particular project team 
and making appropriate improvements where necessary. 

e Conducting general or project-specific training to ensure that personal data is handled 
securely. 

e Creating protocols for information handling within the project, and ensuring that all 
relevant staff are trained in operating under the protocol. 

e Producing guidance for staff as reference point in the event of any uncertainty relating to 
the handling of information. 

e Assessing the need for new IT systems to safely process and store the data, and 
providing staff with training in any new system adopted. 

e Assessing the portability of using anonymised or pseudonymised data as part of the 
project to reduce identification risks, and developing an appropriate anonymisation 
protocol if the use of anonymised data is suitable. 

e Ensuring that individuals are fully informed about how their information will be used. 

e Providing a contact point for individuals to raise any concerns they may have with your 
organisation. 

e If you are using external data processors, selecting appropriately experienced data 
processors and putting in place legal arrangements to ensure compliance with data 
protection legislation. 

e Deciding not to proceed with a particular element of a project if the data privacy risks 
associated with it are inescapable and the benefits expected from this part of the project 
cannot justify those risks. 


In most cases, there are some data protection risks which cannot be eliminated or reduced. 
These risks can be accepted if they are proportionate to the outcomes that will be achieved by 
proceeding with the project notwithstanding the risk. Any decisions to accept data protection 
risks should be recorded in the data protection risk register, or otherwise in accordance with 
your project management process. 


At this stage, you should also ensure that the project will be in compliance with data protection 
laws. In particular, you should consider whether the project complies with the data protection 


principles, and ensuring that you have a good legal basis for processing personal data. 


5. Signing off and recording the DPIA outcomes 


The primary aim of conducting a DPIA is to identify and minimise the data protection risks 
involved in a project. However, as has been emphasised throughout this guide, keeping a record 
of all steps taken as part of the DPIA will help to ensure that the process is completed 
thoroughly, and to reassure stakeholders that all data protection risks have been considered. 
This written record should also form that basis of putting into effect the data protection 
solutions which have been identified, and can be used to check off the implementation of each 
solution. 





There is no requirement to produce a final DPIA report but it is good practice to do so. This 
report should bring together, in summary form, the record keeping from each stage of the DPIA 
process and note the conclusions from each step of the process. It should also include an 
overview of the project, explaining why it was undertaken and how it will impact on data 
protection. It should describe the process adopted in conducting the DPIA, and set out the data 
protection risks and solutions which were identified as part of the process. Your organisation 
may decide to publish the DPIA report or a summary of it. The decision of whether or not to 
publish the report will probably have a bearing on how much detailed information is put into the 
report, as it may not be appropriate to publish commercially sensitive information or 
information containing too much detail about security vulnerabilities which have been identified. 


A DPIA does not necessarily require a formal signing-off process, but your organisation may 
require it, particularly if it recommends significant changes to the nature of a project, or if it 
recommends accepting significant risks. 


If the data privacy risks which have been identified are not capable of mitigation consistent with 
the goals of a project, and it would not be proportionate to accept them, this stage should be 
used for re-evaluating the viability of the project. In such circumstances, an organisation may 
decide to either change the goals of a project to allow for mitigation of data protection risks, or 
abandon the project altogether. 


6. Integrating the DPIA outcomes back into the project plan 


Once it has been signed off, it is necessary to put the findings of the DPIA into action by 
integrating any necessary changes into the plans for the project. The earlier the DPIA can be 
completed, the easier it will be to give effect to the data privacy solutions, but as the DPIA will not 
normally be completed until the project has already progressed somewhat in the planning 
stages, it will normally be necessary to adjust plans to give effect to the data privacy solutions 
identified. 


As part of the implementation of the DPIA, you should keep data protection issues under review. 
In particular, you should assess whether the data protection solutions implemented are having 
the intended effect of mitigating data protection risks. Additionally, if the project aims change or 
expand over its lifetime, it may be necessary to assess whether a further DPIA is required to 
assess the effect of the changes on the data protection risks identified. Such a review can be 
built into your organisation's existing procedures. 


Consulting with the Data Protection Commissioner and publishing the DPIA 


Should the Data Protection Commissioner be consulted on completion of the DPIA? 


If, during the DPIA process, the Data Controller has identified and taken measures to mitigate 
any risks to personal data, it is not necessary to consult with the DPC before proceeding with the 
project. 


If the DPIA suggests that any identified risks cannot be managed and the residual risk remains 
high, you must consult with the Data Protection Commissioner before moving forward with the 
project. 





Regardless of whether or not consultation with the DPC is required, your obligations of retaining 
a record of the DPIA and updating the DPIA in due course remain. 


Even if consultation is not required, the DPIA may be reviewed by the DPC at a later date in the 
event of an audit or investigation arising from your use of personal data. 


Should the DPIA be published? 


It is not legally mandatory to publish the DPIA. However, there are a number of benefits to doing 
so. Publishing the DPIA can help to foster trust in your handling of personal data, and 
demonstrate accountability and transparency, particularly where members of the public are 
affected. This may be especially beneficial for DPIAs carried out by public bodies. 


The published DPIA does not need to contain the whole assessment, especially when the DPIA 
could present information concerning security risks or commercially sensitive information. It 
could even consist of just a summary of the DPIA’s main findings. 





